home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 3 / QRZ Ham Radio Callsign Database - Volume 3.iso / digests / tcp / 930044.txt < prev    next >
Internet Message Format  |  1994-06-04  |  6KB
  1. Date: Tue, 16 Feb 93 04:30:13 PST
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: TCP-Group Digest V93 #44
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Tue, 16 Feb 93       Volume 93 : Issue   44
  11.  
  12. Today's Topics:
  13.                                    
  14.                               16554 UART
  15.                            Mail Path to JT
  16.                                 stat()
  17.                             stat() et. all
  18.                         Stat - Hello wake up !
  19.  
  20. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  21. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  22. Problems you can't solve otherwise to brian@ucsd.edu.
  23.  
  24. Archives of past issues of the TCP-Group Digest are available
  25. (by FTP only) from UCSD.Edu in directory "mailarchives".
  26.  
  27. We trust that readers are intelligent enough to realize that all text
  28. herein consists of personal comments and does not represent the official
  29. policies or positions of any party.  Your mileage may vary.  So there.
  30. ----------------------------------------------------------------------
  31.  
  32. Date: MON, FEB 15 1993 09:23:17
  33. From: Carlton Ellis   <CELLIS%BROCK1P.bitnet@CUNYVM.CUNY.EDU>
  34. Subject: 
  35. To: <tcp-group@ucsd.edu>
  36.  
  37. Sub Carty Ellis KA2Y
  38.  
  39. ------------------------------
  40.  
  41. Date: Mon, 15 Feb 93 15:53:12 MST
  42. From: wbaggett@NMSU.Edu
  43. Subject: 16554 UART
  44. To: TCP-Group@UCSD.Edu
  45.  
  46. Sorry for the noise, but does anybody here know anything about the 16554
  47. UART?  I ran across a 4 port serial i/o card that lets you choose from a
  48. wide range of i/o addresses and IRQ's.  The box says it uses the 16554 and
  49. then says it is 16550 compatible.  The question is, **really**??, including a
  50. working fifo?  I have never seen that chip mentioned before, and it is not in
  51. any of the catalogs I have.
  52.  
  53. Direct replies are fine.  If anybody else wants to know what if any answers
  54. I get, E-mail me direct and I will send same to you.
  55.  
  56. Thanks much.  Tim, AA5DF,  wbaggett@NMSU.edu
  57.  
  58. ------------------------------
  59.  
  60. Date: Mon, 15 Feb 1993 08:19:19 PST
  61. From: David_Shalita.ES_AE@xerox.com
  62. Subject: Mail Path to JT
  63. To: tcp-group@ucsd.edu
  64.  
  65. I am trying without success to send mail
  66. to JT@zfja-gate.fuw.edu:pl.  Please forward this message to him.
  67.  
  68. Hello JT:
  69. Please send me a short note so I can find the proper mail address back to you.
  70. Thanks, Dave
  71.  
  72. ------------------------------
  73.  
  74. Date: Mon, 15 Feb 93 22:10 GMT
  75. From: Ian Campbell <softice@cix.compulink.co.uk>
  76. Subject: stat()
  77. To: crompton@nadc.navy.mil, kz1f@legent.com, tcp-group@ucsd.edu
  78.  
  79. In <24721.9302100918@pyr.swan.ac.uk> Alan Cox writes:
  80.  
  81. > stat can be a bit funny on Borland 3.0 - stat of a drive root fails
  82. > for example. Also stat on a novell directory reports both the file
  83. > and directory bits being set. You just trust the directory one.
  84. > I don't know if 3.1 fixed these odd cases.
  85.  
  86. > Thats my experience anyway with straight BC3.0 and no patches or
  87. > upgrades on it.
  88.  
  89. Checked 3.1 and stat() on drive root appears to work and reports the
  90. directory bit set.
  91.  
  92. Ian
  93. softice@cix.compulink.co.uk
  94.  
  95. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  96.  
  97. ------------------------------
  98.  
  99. Date: Tue, 16 Feb 93 10:30:28 CET
  100. From: dk5dc@vnet.ibm.com
  101. Subject: stat() et. all
  102. To: TCP-GROUP@ucsd.Edu
  103.  
  104. Alan writes:
  105. >> stat() I somehow think will stay in all of the compilers for a long time
  106. >> its in POSIX, and its unix since somewhere near day 1. I'd also suggest not
  107. >> using findfirst() but using opendir() closedir() and readdir() which are
  108. >> _standard_ directory reading facilities.
  109. k1zf writes:
  110.  
  111. > Posix, find me a posix compliant compiler for DOS/WINDOWS/OS2 architectures.
  112. > Find me a posix version of NOS.
  113. > I am familiar with IBM, microsoft and Borland c compilers, I have never seen a
  114. > "standard" oppendir(), closedir() and readdir().
  115. > Alan, the ANSI standards
  116. > committe, for right or wrong, did not include stat().
  117. > Walt
  118.  
  119. I played with the ....dir() functions introduced in BC++.
  120. In my Opinion, those guys lack *essential* information.
  121. I mean, it does not make any sense to use those function for
  122. the benefit of getting just a name and a bunch of strange
  123. fields like _d_magic.......
  124. No filesize, no filedate, no nothin.......
  125. For me, it looks like a typical comittee construct:
  126. lots of participating people, few with practical experience
  127.  
  128. Peter DK5DC/AA6HM
  129.  
  130. ------------------------------
  131.  
  132. Date: Tue, 16 Feb 93 10:02:36 GMT
  133. From: Alan Cox <iiitac@pyr.swan.ac.uk>
  134. Subject: Stat - Hello wake up !
  135. To: tcp-group@ucsd.edu
  136.  
  137. There are times when people annoy me.. I shall try not to make this
  138. a flame.  Walt KZ1F claims to know borland c compilers and has
  139. never seen a standard opendir() closedir() readdir(). Could have
  140. fooled me, dunno how all my programs using opendir() could 
  141. possibly compile unchanged on Borland C.
  142. You don't know a POSIX complaint compiler, I've yet to meet one
  143. I admit, but GCC for OS/2 is pretty close.
  144.  
  145. Findfirst() and findnext() are a pair of almost PC only calls.
  146.  
  147. A summary from the machines I use
  148.  
  149. Type           findfirst      opendir      stat
  150. IBM PC              Y           Y            Y
  151. (DOS/Windows/BC)
  152. CBM Amiga(GCC)      N           Y            Y
  153. Linux(GCC)          N           Y            Y
  154. SYS5.4 (CC)         N           Y            Y
  155.  
  156. Get the idea.
  157.  
  158. In addition emulating the MSDOS findfirst/next calls in most
  159. operating systems isn't possible because DOS times are accurate
  160. to only 2 seconds and the years begin in 1980. It is trivial
  161. to write a unix stat() call in terms of the DOS findfirst/next
  162. interrupts.
  163.  
  164. I think it's rather obvious which way to go, especially since
  165. contrary to some people's belief NOS gets ported onto other
  166. things than DOS - AmigaNOS for example, and bits of it keep
  167. getting added to things like the Unix NET.
  168.  
  169. KA9Q in the DOS world has already got itself trapped and dependant
  170. on a paticular species of a paticular compiler. If anything the
  171. way forward with NOS is a specify set of standard facilities
  172. locked firmly away in machine specific subdirectories and a 
  173. standard commonly found set of functions for acheiving most
  174. things - it's even mostly there.
  175.  
  176. Alan
  177.  
  178. ------------------------------
  179.  
  180. End of TCP-Group Digest V93 #44
  181. ******************************
  182. ******************************
  183.